This invention relates to a method of operating a transaction processing system, and to the transaction processing system itself. The invention may be used to provide deadlock avoidance for recoverable requests.
In computer science, transaction processing is a system of processing that is divided into indivisible units called transactions or tasks. Each transaction, or task, must succeed or fail as a complete unit. A transaction cannot remain in an intermediate state. Transaction processing is designed to maintain a computer system, such as a database, in a known and consistent state by ensuring that any operations in a transaction are either all completed successfully or all cancelled successfully. If some of the operations in a transaction are completed, but errors occur when another operation is attempted, the transaction processing system rolls back all of the operations of the transaction, including the successful ones, thereby removing all traces of the entire transaction and restoring the system to the consistent, known state that it was in before the processing of the transaction began. If all operations of a transaction are completed successfully, the transaction is committed by the system, and all changes are made permanent.
A known problem in transaction processing systems is deadlock. In some cases, two transactions may, in the course of their processing, attempt to access the same portion of a database at the same time, in a way that prevents them from proceeding. For example, transaction A may access portion X of the database, and transaction B may access portion Y of the database. If, at that point, transaction A then tries to access portion Y of the database while transaction B tries to access portion X, a deadlock may occur, and neither transaction may be completed. Transaction processing systems are designed to detect these deadlocks when they occur. Once way to resolve the problem is for both transactions to be cancelled and rolled back, and then they will be started again in a different order, automatically, so that the deadlock does not occur again. Alternatively, just one of the deadlocked transactions will be cancelled, rolled back, and automatically re-started after a short delay. Deadlocks may also occur between multiple transactions.
In a transaction processing environment multiple tasks may attempt to make multiple requests to several recoverable resources atomically. Exclusive use of a resource is used to ensure that only one task at a time has read/write access to a resource. Shared use of a resource is used to ensure that, when browsing through a sequential list of items, a task does not lose its position. Deadlocks may occur in this environment. These are normally resolved by aborting one of the two or more tasks involved in the deadlock. A self deadlock, where a single task becomes deadlocked with itself, through obtaining a shared lock on a resource and then later attempting an exclusive lock on the same resource, is also normally resolved in this way.
Aborting tasks may cause an integrity problem if the task(s) to be aborted, to break the deadlock, should not be aborted, for example if a task is in backout. Even if integrity is maintained, this method is still disruptive, and adds processing time to restarting the transactions from the beginning. A more robust and efficient method is needed to resolve deadlocks.